An important distinction in the nature of computer software is the distinction between software that is written in a complied language and software that is written in an interpreted language. When software is written in a complied language, a software provider may license associated machine code to customers. When software is written in an interpreted language, however, only the source code itself is available for licensing.
Source code is run by an interpreter, which executes each source-code instruction individually. Unfortunately, exposing the source code to an interpreter opens the risk that an unauthorized party will copy, alter, distribute, or reverse engineer the software. Thus, a software provider must often choose between the security offered by a compiled language and the simplicity and efficiency offered by an interpreted language.
Often, this means that a software provider must develop software twice: a first time in an interpreted language for prototyping and internal use, and a second time in a complied language for secure distribution to licensees. For example, an application program for the world wide web might first be developed in PERL for internal use, and then redeveloped in Java for external licensing.
One way to resolve this dilemma is to use a PERL compiler, which converts PERL scripts into C language code, and from this provide machine code. Notwithstanding, such an approach has at least three disadvantages. First, the solution is specific to the PERL language; second, in practice the compiled C code does not always execute properly; and third, an unauthorized party may be readily able to decompile the resulting machine code.
Another way to resolve the dilemma is to encrypt the source code. Following this approach, a licensee is provided with an encrypted source code file and with integrated decoding software that both decrypts and interprets the encrypted source code file. Unfortunately, this approach also has significant disadvantages. Chief among these is the disadvantage that the integrated decoding software is necessarily language dependent. For example, integrated decoding software useful for encrypted PERL source code files is not useful in the realm of any other programming language. Hence a software provider or a software licensee who works with a multiplicity of interpreted languages bears the inconvenience and expense of a multiplicity of integrated decoding software programs.
Thus there is a need for a way of protecting software written in interpreted languages that is convenient and secure, and which applies generically without dependence upon the particular interpreted language of choice.